Night Owl 19

home *** CD-ROM | disk | FTP | other *** search

/ Night Owl 19 / Night Owl (The Best of Shareware)(NOPV 19)(1996).ISO / 018a / rgsn1295.zip / RGSNET.POL < prev next >

Wrap

Text File | 1995-12-15 | 47KB | 998 lines

R G S N E T Renegade Support Network Policy and Procedures Guide Draft 2.0c October 29, 1995 ============================================================================== Chapter 1 OVERVIEW ============================================================================== 1.0 Language The official language of RGSNet is English. All documents must exist in English. Translations to other languages is encouraged. 1.1 Objective To connect Renegade Systems across the Nation and the World into a FidoNet Compatible Network for the "Free Exchange of Information." We (The Renegade Support Network) have no intentions of trying to replace or compete with the existing FidoNet Network. We (The Renegade Support Network) only want a means of communicating directly with other Renegade SysOps across the nation and to enhance the transmission of messages across the nation and to further develop Renegade. This document is an attempt to describe the procedures which have been developed to manage The Renegade Support Network (RGSNet). 1.2 Background FidoNet is an amateur electronic mail system. From its early beginnings as a few friends swapping messages back and forth, it has now grown to (June 1994) over 25000 different systems on four continents. RGSNet is attempting to provide the resources to a Renegade System Operator (SysOp) and the tools to connect into a Network of other Bulletin Board (BBS) SysOps across the nation. We are also able to provide partial international connectivity as well. RGSNet will not try to reinvent the wheel. We will adopt most of of the standards that International FidoNet Association has already adopted into their network. 1.3 Definitions RGSNet nodes are grouped on several levels. These are as follows: Nodes: A node is a single Net address, and is the smallest recognized unit of the Net. Hubs: A hub is a collection of nodes, usually in a relatively small geographic area. Hubs coordinate their mail activity to decrease cost and increase mail throughput. Networks: A collection of hubs/nodes within a slightly larger geographic area (an individual state for example). Networks are treated just like large hubs. Therefore, all that applies for Hubs ... also applies for Networks. Regions: A collection of a group of networks within a specified geographical region, usually several states grouped together. A region is a well defined geographic area containing nodes which may or may not be combined into networks. A typical region will contain many nodes in networks, and a few independent nodes, which are not a part of any network. Zones: (Not applicable) A zone is a large geographic area containing many regions, and covering one or more countries and/or continents. RGSNet: This indicates the entire mail network, as designed by the Renegade Support Network Coordinators and as defined by the weekly nodelist. 1.4 The Levels of RGSNet With the introduction of The Renegade Support Network, RGSNet has developed the following levels of organization: The Zone Coordinator The Zone Coordinator compiles all of the nodelists for the entire Zone and creates the master nodelist, which is then distributed across The Renegade Support Network. Any disputes at the Regional level are handled by the Zone Coordinator and/or his assignees. The Regional Coordinator The Regional Coordinator is responsible for maintaining the list of Networks for his Region, and for receiving and forwarding any mail coming to the region from the outside. He is also responsible for the maintenance of the members of his region and will ensure proper use of the network by those members. Any disputes at the Network Level are handled by the Regional Coordinator and/or his assignees. The Network Coordinator The Network Coordinator is responsible for maintaining the list of nodes for his network, and for receiving and forwarding any mail coming to the network from the outside. He is also responsible for the maintenance of the members of his network and will insure proper use of the network by those members. Any disputes at the Network Routing Hub Level are handled by the Network Coordinator and/or his assignees. The Network Routing Hub Network Routing Hubs exist only in three-tiered networks. They generally share some or all of the duties of the Network Coordinator, in order to ease the management of a large network. The exact duties and procedures are a matter for the Network Coordinator and his hubs to settle, and will not be discussed here. The Network Coordinator is still responsible for the maintenance of the network and insures proper use of the network for the people in his Routing Hub. All disputes at the node level, should be addressed by the Routing Hub, before being forwarded to the Network Coordinator. The System Operator (SysOp) The SysOp formulates his own policy for running his board and dealing with his users, so that will not be discussed in this document. However, the sysop must also mesh with the rest of the RGSNet Systems if he is to send and receive mail, and that will be discussed here. The User Policy and procedures for the individual user on any given board is determined by the system operator of that board, and will not be considered in this document. These levels act to distribute the administration and control of RGSNet to the lowest possible level, while still allowing for coordinated action over the entire mail system. ============================================================================== Chapter 2 SYSOP PROCEDURES ============================================================================== A SysOp of an individual node can pretty much do as he pleases, as long as he observes the mail events, is not excessively annoying to other nodes on RGSNet or any other FidoNet Compatible Network, and does not promote the distribution of pirated copyrighted software. National Mail Hour (also known as ZMH, or Zone Mail Hour) is the heart of any Netmail Network, as this is when the network mail is passed between systems. Any system which wishes to be a part of a NetMail Network must be able to receive mail at this time. A system which is a member of a network may also be required to observe additional mail events, as defined by his Network Coordinator. Network mail systems generally operate unattended, and place calls at odd hours of the night. If a system tries to call an incorrect or out of date number, it could cause some poor citizen's phone to ring in the wee hours of the morning, much to the annoyance of innocent bystanders and civil authorities. For this reason, a SysOp who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practical. The exact timing of National Mail Hour is set for the zone by the Zone Coordinator. In the United States, National Mail Hour is observed from 0900 to 1000 GMT (Greenwich Mean Time) every day, weekends included. In each of the United States time zones, this would be as follows: Eastern Standard Time 4 AM to 5 AM Central Standard Time 3 AM to 4 AM Mountain Standard Time 2 AM to 3 AM Pacific Standard Time 1 AM to 2 AM Hawaii Standard Time 11 PM to 12 Midnight Networks do not observe daylight savings time. In areas which observe daylight savings time the RGSNet mail schedules must be adjusted in the same direction as the clock change. Alternatively, you can simply leave your system on standard time. Since on occasion, polling your assigned hub or host (read: administrative link) can be more costly than polling another hub or host, we have made it possible for you to find the most inexpensive link to the network. Polling outside of your assigned hub or host is allowed, however, certain guidelines must be followed: 1. You must poll your assigned hub or host at least once per week for the following: * Routed or indirect netmail (we will not perform special routing) * Mandatory File Echos: RGSF_ADMI, RGSF_LIST, RGSF_DIFF. * Any *LOCAL* Administrative Echos (i.e. RGS_REG51, RGS_NET190) 2. You must abide by any rules governed by your assigned hub or net. 2.1 How to get a node number You must first obtain a current nodelist so that you can send mail. You do not need a node number to send mail, but you must have one in order for others to send mail to you. The first step in obtaining a current nodelist is to locate the closest RGSNet Bulletin Board System to you. If the SysOp of any RGSNet system does not have a nodelist available for downloading, then he can probably tell you where to get one, BUT we STRONGLY suggest all nodes carry and allow for download the most recent RGSNLIST.Z?? and related RGSNet files. Once you have a nodelist, you must determine which network or region covers your area. If you are unsure of this or there is not one in your area, send the information to the Zone Coordinator @ 50:50/0. Once you have located the network or region in your area, send a request for a node number to node zero of that network or region. The request must be sent by a NetMail message and must include at least the following: 1) Your name. 2) The name of your system. 3) The city and state where your system is located. 4) The phone number to be used when calling your system. 5) Your hours of operation. 6) The maximum baud rate you can support. 7) BBS Software Version. 8) NetMail Interface Program. 9) A list of EchoMail Conferences that you wish to pick up. 10) Voice number (Internal use only!). Your coordinator may want additional information. If so, he/she will contact you. Please allow at least five working days for a node number request to be processed. If you send your request to the Zone Coordinator, then he may forward your request to the Network Coordinator who covers your area (if any), which may take longer. 2.2 If you are going down If your node will be down for an extended period (more than a day or two), then you should inform your coordinator as soon as possible. If you do not do this, then other systems will still try to reach you while you are down, much to the annoyance of everyone. Do not under any circumstances put an answering machine or similar device on your phone line while you are down. If you do, then calling systems will get the machine repeatedly, racking up large phone bills, which is VERY annoying. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your coordinator. Systems _do_ have a tendency to "crash" now and then, so you will probably want your coordinator to know that it is a temporary condition if it happens while you are away. 2.3 How to join a network If you are an independent node and would like to join a network in your area, you must contact the Network Coordinator. He can be reached by sending Netmail to node zero of the network. He will inform you of any special mail schedules and/or routing required by the network. Once you have been placed in the network, you will be informed by the Network Coordinator. There are many advantages to being in a network. First and foremost is that it helps reduce congestion of RGSNet during National Mail Hour. Also, many networks are "outbound" as well as "inbound", which can substantially reduce your phone bills. In addition, network members receive regular updates of the nodelist, while an independent node may not. 2.4 How to form a network If there are several nodes in your area, but no network, then you may wish to form your own. Again, this has several advantages as outlined above. Your first step is to contact the other SysOps in your area. You must decide which nodes will comprise the network, and which of those nodes is going to be the Network Coordinator. Your next step is to inform Network Administration. You must send him a NetMail message with the following information: 1) The region number(s), or network number(s) if a network is splitting up, that are affected by the formation of your network. The Regional Coordinator will inform the Zone Coordinator and the coordinators of any affected networks that a new network is in formation. 2) The name that you wish to call your network. Please try to select a name that relates to your grouping. For example, SoCalNet for nodes in the Southern California Area and MassNet for Massachusetts Area. Remember if you call yourself DOGNET it doesn't help others know what area of the country (or even what country) your group is in. 3) A copy of the proposed network's nodelist. The nodelist file should be named RGSNET.nnn where "nnn" is the proposed host's current region or network number. This file should be sent attached to the message of Application for a Network Number. SAMPLE FORMAT OF A RGSNET.100 FILE Host,100,California_NET,North_Palm_Springs_CA,Scott_Freeman,1-619-251-0609,9600, CM,XA,V32b,V42b ,1,Alternate_Reality,North_Palm_Springs_CA,Scott_Freeman,1-619-251-1675,9600,CM, XA,V32b,V42b ,2,Olympus_BBS,Cathedral_City_CA,Mike_Partelow,1-619-324-2526,9600,CM,XA,V32b,V4 2b ,3,Desert_Night,Oceanside_CA,Rodney_Dunn,1-619-430-7734,9600,CM,XA,V32b,V42b,MNP ; Granting of a network number is not automatic. Network Administration will review your application and inform you of the decision. ============================================================================== Chapter 3 NETWORK COORDINATOR PROCEDURES ============================================================================== A Network Coordinator has the following responsibilities: 1) To receive incoming mail for nodes in his network, and to deliver it to its recipients. This mean you have to poll the Regional Coordinator or Mail Distribution System to receive your mail. 2) To assign node numbers to nodes in his network. 3) To maintain the nodelist for his network, and to send a copy of it to the Regional Coordinator whenever it changes. 4) To pass along to his nodes the new nodelist, nodelist updates and new issues of RGSN????.ZIP as they are received. 3.1 Routing inbound mail It is your responsibility as Network Coordinator to receive all inbound mail for nodes in your network and to forward it to its recipients. You are left to your own discretion as to how best to accomplish this. If a node in your network is routing large volumes of EchoMail, you can ask him to either limit the amount of EchoMail, or even to stop routing his EchoMail completely. The design of EchoMail is such that it is a simple matter to do either of these. Or they can break off out of your network. 3.2 Assigning node numbers It is your responsibility to assign node numbers to new nodes in your network. You may also change the numbers of existing nodes in your network, though you should check with your member nodes before doing so. You may assign any numbers you wish, so long as each node has a unique number within your network. 3.3 Maintaining the nodelist You should attempt to implement name changes, phone number changes, etcetera in your nodelist as soon as possible, and to forward the revised Nodelist to your Regional Coordinator whenever a change occurs. You should also on occasion send a message to every node in your network to ensure that they are still operational. If a node turns out to be "off the air" with no prior warning given to you, then you can either mark the node as down, make it temporarily inactive, or remove it from the nodelist completely, at your own discretion. 3.4 Passing along nodelists and RGSNet Info Packets As a Network Coordinator you should obtain a new nodelist update every week. The nodelist update is posted weekly on Saturdays. The list will be made available to you by Network Administration. You should pass both of these along to your member nodes as soon as is practical after you receive them. It is also desirable that you make them both available for downloading by the general user, but this is not required. The nodelists are the glue that holds us together. Without them, we cease to be a community, and become just another random collection of bulletin boards. ============================================================================== Chapter 4 REGIONAL COORDINATOR PROCEDURES ============================================================================== Regional Coordinators have the following responsibilities: 1) To assign node numbers to independent nodes in the region. 2) To encourage independent nodes in the region to join existing networks or to form new networks. 3) To assign network numbers to networks in the region. 4) To compile a nodelist of all of the networks and independents in the region, and to send a copy of it to the Mail Distribution Node whenever it changes. 5) To ensure the smooth operation of the networks within the region. 4.1 Assigning Node numbers The responsibility to assign node numbers to new network in the region. You may also change the numbers of existing networks in the region, though you should check with the respective nodes before doing so. The numbers assigned to networks must be within the RGSNet Network Plan in order for future growth of the region to be possible. You should use network mail (netmail) to inform a new node of their node number, as this helps to insure that he is capable of receiving network mail. If you receive a node number request from a new node that is in an area covered by an existing network, then you should forward the request to the Coordinator of that network instead of assigning a number yourself. 4.2 Encouraging the formation and growth of networks One of your main duties as the Regional Coordinator is to promote the growth of networks in the region. You should try to avoid having independent nodes in the region which are within the coverage area of a network. There are, however, certain cases where a node should not be a member of a network, such as a commercial system with a large volume of traffic which would clog the network. The resolution of such special cases is left to your own discretion. If several independent nodes in your region are in a "clump", then you should encourage them to form a network. Refer to the SysOp procedure forming a network on forming a network for details of what information you should get. Note that this does not mean to encourage the formation of trivial networks. Obviously, one node does not make a network. The exact number of nodes required for an effective network must be judged according to the circumstances of the situation, and should be according to the plan of the region. 4.3 Assigning network numbers It is your responsibility to assign network numbers to new networks forming within your region. The network numbers are assigned by referring to the RGSNet Network Plan. 4.4 Maintaining the nodelist The Regional Coordinator has a dual role in maintaining the nodelist for the region. First, you must maintain the list of independent nodes in your region. You should attempt to implement name changes, phone number changes, and so forth in this nodelist as soon as possible. You should also on occasion send a message to every independent node in your region to ensure that they are still operational. If a node turns out to be "off the air" with no prior warning given to you, then you can either mark the node as down, make it temporarily inactive, or remove it from the nodelist completely, at your own discretion. Second, you must receive the nodelists from the Network Coordinators within your region. You should assemble a master nodelist for your region every week and send it to the Zone Coordinator no later than National Mail Hour on Friday morning. It is suggested that you do this as late as is practical, so as to accommodate any late changes. You will need to maintain a set of nodelists for each network within your region, since you cannot count on getting an update from each Network Coordinator every week. 4.5 Overseeing network operations It is the responsibility of Regional Coordinator to ensure that the networks within the region are operating in an acceptable manner. This does not mean that you are required to operate those networks, that is the responsibility of the Network Coordinators. It means that you are responsible for seeing to it that the Network Coordinators within your region are acting responsibly. It is the obligation of Regional Coordinator to maintain direct and reasonably frequent contact with the networks in the region. The exact method of accomplishing this is left to your discretion. 4.6 Passing along nodelists and RGSNet Info Packets Regional Coordinators are responsible for obtaining the latest RGSNet nodelist updates and any RGSNet Info Packets as they are published, and to make them available to the Network Coordinators within your region. The Nodelist is posted weekly on Saturday's by RGSNet HQ @ Node #50:50/0. It is your responsibility to distribute these to any Network Coordinators in your region as soon as is practical after you receive them. The method of distribution is left to your discretion. You are not required to distribute them to any independent nodes in your region, though you may if you wish. It is also desirable that you make them both available for downloading by the general user, but this is not required. ============================================================================== Chapter 5 ECHOMAIL CONFERENCES ============================================================================== EchoMail Conferences are messages that are passed around the nation and the world. These conferences can range from very technical topics to very casual ones. Some may even have offensive language in them. So, it is very important that you only choose the ones that would be of interest to you and/or your users. You can always add and/or delete the conferences that you choose. For a current list of the available EchoMail Conferences, ask your Network Coordinator for the current list. It will also be available for download and/or file requestable from Mail Distribution @ 50:50/0 as "RGSNET.NA". If you are receiving EchoMail Conferences from RGSNet, it is mandatory that you NOT forward RGSNet or any another Network EchoMail Conferences to NON-RGSNet Systems. Also, do not accept feeds of the same EchoMail Conference from more than one source. If you do, it will create duplicate messages in EVERYONES Network. Violation of this will not be tolerated! The following are REQUIRED RGSNet EchoMail Conferences: RGS_ADMI This is a PRIVATE Conference which is only available to nodes of RGSNet. This conference will be used for the development of The Renegade Support Network. This should be listed in your configurations as "sysop-only"! This Echo Mail Conference is ONLY for RGSNet Development Information and should not be used for anything else. This echo should be flagged as REAL NAMES only. Moderator: Scott Freeman @ 50:50/0 RGS_HUBS This is a PRIVATE Conference which is only available to the RGSNet Hub Managers. This conference will be used for Hub Manager Information between them and RGSNet Network Administration. This should be listed in your configurations as "sysop-only"! This echo should be flagged as REAL NAMES only. Moderator: Scott Freeman @ 50:50/0 RGS_HOST This is a PRIVATE Conference which is only available to the RGSNet Network Managers. This conference will be used for Net Manager Information between them and RGSNet Network Administration. This should be listed in your configurations as "sysop-only"! This echo should be flagged as REAL NAMES only. Moderator: Scott Freeman @ 50:50/0 RGS_REGION This is a PRIVATE Conference which is only available to the RGSNet Regional Managers. This conference will be used for Regional Manager Information between them and RGSNet Network Administration. This should be listed in your configurations as "sysop-only"! This echo should be flagged as REAL NAMES only. Moderator: Scott Freeman @ 50:50/0 The following are OPTIONAL RGSNet EchoMail Conferences: ALT.BBS.RENEGADE This is a PUBLIC Conference which is available to all RGSNet Members. It is a gated echo from the Usenet Newsgroup of the same name. This echo requires that you turn off all origins and kludge information in your base configuration. It is provided to us by our Internet GateWay Host, Percy Dieppa (pdieppa@dynamics.nlbbs.com). Aliases are allowed. Moderator: Percy Dieppa @ 50:280/0 RGS_ADS This is a PUBLIC Conference which is available to all RGSNet Members. It will be used for BBS and OTHERNET ads (FOR SALE ads should be posted in the RGS_FORSALE echo). It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Richard Plantz @ 50:53/0 RGS_AVSEC This is a PUBLIC Conference which is available to all RGSNet Members. It will be used for discussions on all Anti-Virus and Security issues. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Jon McKenzie @ 50:500/307 RGS_BATCH This is a PUBLIC Conference which is available to all RGSNet Members. It will be used for discussions of batch programming issues and questions. 4DOS and other batch programming issues are allowed. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Don Cranford @ 50:57/0 RGS_BRE50 This is a PUBLIC Conference which is available to all RGSNet Members. It will be used for league members to discuss game issues and problems. It can be made available to the callers of your system on an RGSNet Node. Aliases are allowed. Moderator: Scott Freeman @ 50:50/0 RGS_BUGS This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss found and newly reported bugs in the Renegade BBS system and related utilities. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: [OPEN] RGS_CHAT This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss anything *not* related to Renegade. It was created for the PUBLIC, but all are welcome to use it. It can be made available to the callers of your system on an RGSNet Node. Aliases are allowed. Moderator: Conrad Estes @ 50:100/17 RGS_COMM This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss anything related to modem communications. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: [OPEN] RGS_DOORS This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss doors and their operation with the Renegade BBS system. It can be made available to the callers of your system on an RGSNet Node. Aliases are allowed, but your REAL NAME must appear in the signature of the message. Moderator: David Pinch @ 50:300/103 RGS_FILE This is a PUBLIC Conference which is available to all RGSNet Members. It will be used by the RGSNet File Echo Coordinator to announce newly hatched files in the RGSFBONE (RGSNet Filebone), for others to announce newly received files (Non-RGSFBONE *ONLY*), available for freqs and will also serve as an area for FILEFIND requests. It can be made available to the callers of your system on an RGSNet Node. Aliases are allowed. Moderator: Mike Fergione @ 50:610/0 RGS_FORSALE This is a PUBLIC Conference which is available to all RGSNet Members. It will be used for all types of FOR SALE ads, either commercial or non-commercial in nature. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Richard Plantz @ 50:53/0 RGS_HARDWARE This is a PUBLIC Conference which is available to all RGSNet Members. It will be used for discussions of all hardware issues and questions. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Rodney Dunn @ 50:100/1500 RGS_INET This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss the Internet and it's operation with the Renegade Bulletin Board System. It can be made available to the callers on your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Dave Ferber @ 50:100/0 RGS_LANS This is a PUBLIC Conference which is available to all RGSNet Members. It will be used for discussions of Local Area Networks (LANS) and other networking issues. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Richard Shiflett @ 50:140/752 RGS_MAILER This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss Front-End Mailers and their operation with the Renegade Bulletin Board System. It can be made available to the callers on your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Ryan Samples @ 50:360/200 RGS_OPSYS This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss the different types of operating systems and environments under which Renegade is run. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: [OPEN] RGS_PROG This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss programming and programming issues that deal with the Renegade Bulletin Board System. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Brian Bosscher @ 50:110/700 RGS_QUES This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss commonly asked questions about Renegade BBS. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Cindy Ingersoll @ 50:130/20 RGS_READERS This is a PUBLIC Conference which is available to all RGSNet Members. It will be used for discussions of Offline Mail Readers and their use with the Renegade Bulletin Board System. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Craig Pease @ 50:230/0 RGS_RGUTIL This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss newly released software for the Renegade Bulletin Board System. This conference was conceived to give a place for authors of 3rd Party Software to discuss the various nuances of their programs. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Richard Shiflett @ 50:140/752 RGS_RENEGADE This is a PUBLIC Conference which is available to all RGSNet Members. This is Cott Lang's Fido RENEGADE (NB) echo. It is gated to other networks. It will be used to discuss the Renegade Bulletin Board System. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Cott Lang @ 1:133/6501@fidonet.org RGS_RGBBS This is a PUBLIC Conference which is available to all RGSNet Members. This is the Fido backboned RENEGADE_BBS echo. It is gated to other networks. It will be used to discuss the Renegade Bulletin Board System. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: Chuck Detwiler @ 50:530/150 RGS_RIPG This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss RIP (Remote Imaging Protocol) and various other utilities associated with RIP and how they interact with the Renegade Bulletin Board System. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: [OPEN] RGS_SUPP This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss general Renegade Support not found in the RGS_QUES forum. It will also be used for announcing new members in the Renegade Support List authored by Sean Dunbar and sanctioned by the Renegade Support Network. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: [OPEN] RGS_SUGG This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss any and all suggestions for improving the Renegade Bulletin Board System. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: [OPEN] RGS_SYSOP This is a PRIVATE Conference only available to nodes of RGSNet. This conference will be used for the discussion of Sysop related topics, NOT covered in other forums, concerning the operation of the Renegade Bulletin Board System. This should be listed in your configurations as "sysop-only"! This echo should be flagged as REAL NAMES only. Moderator: Lenny Baker @ 50:580/0 RGS_TICS This is a PUBLIC Conference which is available to all RGSNet Members. It will be used to discuss file echo processors and their use with the Renegade Bulletin Board System. It can be made available to the callers of your system on an RGSNet Node. This echo should be flagged as REAL NAMES only. Moderator: [OPEN] ============================================================================== Chapter 6 Renegade Support Network CONTACTS ============================================================================== Scott Freeman Network Administrator P.O. Box 1141 N. Palm Springs, California 92258-1141 (D) 619-862-0072 RGSNet Node #50:50/0 Email blazenet@ix.netcom.com Mike Fergione File Distribution Coordinator Parker, Colorado (D) 303-841-5515 RGSNet Node #50:610/0 Percy Dieppa Internet Gateway Westbrook, Maine (D) 207-854-8529 RGSNet Node #50:59/0 Email pdieppa@dbbs.mainelink.net Jeff Fanjoy RGSNet WWW Home Page Etobicoke, ON (D) 416-251-3733 RGSNet Node #50:660/309 Email jfanjoy@interlog.com ============================================================================== Chapter 7 ACKNOWLEDGMENTS ============================================================================== IFNA The International FidoNet Association for creating standards for Packet Mail to be transmitted across the nation. Renegade Renegade Bulletin Board Service Program written by Cott Lang. RGSNet The Renegade Support Network created by Joe Farrell. Squish The Zone Aware EchoMail Packer and Router Program which was written by Scott Dudley. Allfix The File Echo Processor by Harald Harms. ReneMail A program written by Cott Lang that allows a SysOp to pull EchoMail Conferences into Renegade. Rodney Dunn For all his help with Nodelists and Internet Gates. Joe Farrell For creating the idea of a network where Renegade Sysops could help each other. Freeman Family I would like to thank them for allowing me the time to work on my (expensive) hobby.